Flexibility in Object-Oriented Operating Systems: A Review

This report presents a review of recent research into exible operating systems. In this context, exible operating systems are taken to be those whose designs have been motivated to some degree by the desire to allow the system to be tailored, either statically or dynamically, to the requirements of speci c applications or application domains. We begin by presenting a review of recent research into exible system software with particular emphasis on the motivations for providing exibility and the di erent approaches to achieving exibility that are available. We then provide an overview of the main technologies for achieving exibility in system software that have been employed. As it turns out, the use of object orientation is a common feature of many exible operating systems. Thus, in order to more fully illustrate the use of object-orientation to achieve exibility, we review a number of the most in uential object-oriented operating systems in detail. Document Identi er TCD-CS-96-05 Document Status Technical Report Created 12 July 1996 Revised 24 May 1996 Distribution Public c 1996 TCD CS Permission to copy without fee all or part of this material is granted provided that the TCD copyright notice and the title of the document appear. To otherwise copy or republish requires explicit permission in writing from TCD. 1 TOWARDS FLEXIBLE OPERATING SYSTEMS 1 This report presents a review of recent research into exible operating systems. In this context, exible operating systems are taken to be those whose designs have been motivated to some degree by the desire to allow the system to be tailored, either statically or dynamically, to the requirements of speci c applications or application domains. Section 1 presents a review of past research into exible operating systems with particular emphasis on those that have employed object-oriented techniques to achieve exibility. As will be seen, the use of object orientation is a common feature of many exible operating systems. Section 2 continues from section 1 by reviewing a number of the most in uential objectoriented operating systems in detail. Finally, Section 3 summarises the report and provides some perspectives on the use of object-orientation to achieve exibility in system software. It should be noted that this report presents only a summary of our review. A more complete presentation of this review is available on the World Wide Web (www) and includes links to www pages describing groups, projects, and individuals currently doing research in this area as well as an annotated bibliography containing several hundred entries [17]. 1 Towards Flexible Operating Systems Operating-systems research has always been driven by developments in technology as well as by goals such as improved performance, increased modularity, and the desire to improve exibility. Technological developments such as the introduction of reduced instruction set architectures, the increased availability of shared-memory multi-processors, or the widespread deployment of high-speed and high-bandwidth networks continue to have an enormous impact on the design of new operating systems. Improving the performance of the various services traditionally provided by operating systems such as thread management, virtual memory, or the le system has likewise always been at the heart of operating-systems research. Recently, perhaps in response to the accelerating pace of advances in technology, increased modularity has also become an important goal both to improve portability and to make system development and maintenance easier. Finally, exibility { the ability to design systems that can be tailored to the requirements of speci c applications or application domains { has always been something of a holy grail for the designers of operating systems. This has never been more so than at present as is evident from recent workshops and conferences such as [3] or [4]. 1.1 Why Flexibility? In [24], Draves identi es a number of problems that can be addressed by making operating system software more exible: feature de ciency: the operating system does not provide some feature required by the application; performance: (some) operating system services do not provide performance that is acceptable to the application; version skew: the application is dependent on a di erent version of the operating system for its correct operation. 1 TOWARDS FLEXIBLE OPERATING SYSTEMS 2 To these might be added \feature abundance". Feature abundance occurs when the operating system provides super uous features that, although not used by the application, result in some (avoidable) runtime overhead. Clearly, increased exibility should allow operating systems to be more easily tailored to provide (only) the features required by the applications to be supported. It is perhaps not so obvious how increasing exibility might improve performance. The essential observation is that every operating system embodies particular trade-o s concerning the way in which the services that it provides are implemented. Typically, in general-purpose operating systems, these tradeo s are made to suit the requirements of what are perceived to be typical applications. The resulting trade-o s will certainly not be the right ones for every application resulting in suboptimal performance for some applications. There is a substantial body of evidence showing that, for some applications at least, exploiting knowledge of the application in making these trade-o s can substantially improve performance. Kiczales et al. [48] use the term mapping dilemma to refer to these trade-o s and characterise a mapping dilemma as a \crucial strategy issue whose resolution will invariably bias the performance of the resulting implementation". Decisions as to how to resolve mapping dilemmas are called mapping decisions and a mapping con ict occurs when the application performs poorly as a result of an inappropriate mapping decision. Increased exibility is intended to allow mapping decisions to be more easily made on an application-speci c basis. 1.2 Approaches to Achieving Flexibility Two basic approaches to achieving exibility can be distinguished: static exibility and dynamic exibility. Static exibility allows system software to be tailored to one application, set of applications, or some particular hardware con guration, as required, at its build time, i.e., when it is compiled, linked, or loaded (depending on the software development process used). Dynamic exibility allows system software to be tailored to the needs of current applications at run time. Three major approaches to building dynamically exible system software can be identi ed. One approach is to build general-purpose systems that provide services supporting a range of di erent policies, which are suitable for the requirements of a wide range of applications, together with a set of service-speci c interfaces allowing applications to have input into the choice of policies to be used according to their particular requirements. Such systems have been variously referred to as supporting selection [49] or parametric variation [8] and are referred to in this report as being adaptable. Examples of adaptable systems include the SunOS operating system, which allows applications to provide advice to the virtual memory system via the madvise system call, and the Mach microkernel whose thread scheduling subsystem also accepts hints from applications as described in [11]. Although few systems support it, a further step in this direction would be to have the system itself choose the appropriate policies to be used for particular applications from those available { perhaps based on analysis of their past behaviour. Such systems are referred to in this report as being adaptive. Another approach to building dynamically exible system software is to allow the application to be involved in some way in the implementation of a service, perhaps by having the service make an upcall to a module, provided by the application, that implements some policy required by the 1 TOWARDS FLEXIBLE OPERATING SYSTEMS 3 service [49], or by allowing the application to interpose code at the interface to the service [8]. Such systems are referred to in this report as being modi able. Examples of systems supporting this kind of exibility include both the Mach and Chorus microkernels, via their external pager interfaces [67, 1], and the system call interposition toolkit for Mach 2.5 described in [39]. The other major approach to building dynamically exible system software is to provide a means of allowing (some) system services to be added or replaced at run time in order to support new or di erent functionality for particular applications. Such systems are referred to in this report as being con gurable and also extensible if they support the addition of new system services as well as replacement of existing services. Most microkernel-based operating systems are con gurable in that they allow those parts of the operating system implemented as usermode servers to be installed or replaced at runtime. The Spin microkernel also allows services to be installed dynamically into the kernel [9]. (Obviously, supporting multiple mechanisms and policies simultaneously or the ability to dynamically add or replace system services incurs some runtime overhead.) To build statically exible system software requires a system architecture that can be implemented in a number of di erent ways in order to include the mechanisms and policies required by di erent applications. The system architecture typically describes a number of subsystems of which di erent implementations exist. A system is built by choosing from the available subsystem implementations at build time. New implementations of particular subsystems can obviously be provided as required. Such systems are referred to in this report as being customisable. Examples of customisable systems include the Choices [19] and Peace [65] operating systems. In the case of static exibility, the system architecture may be said to be extensible if it has been designed to facilitate the introduction of further subsystems, which provide additional functionality that is not already provided for by the architecture. The various approaches to achieving exibility are not mutually exclusive and di erent systems may employ more than one. For example, the Peace operating system can be con gured dynamically [60]. It is also worth noting that the distinction between a customisable system and a con gurable one may be small in practice. A con gurable system that provides minimal mandatory functionality but allows the system services required by a particular application to be loaded dynamically is very close to a customisable system. The former has at least some xed component and may incur overheads in accessing system services that are dynamically loaded. 1.3 Qualities of Flexible System Software Flexibility, however it is supported, is not a binary attribute; di erent systems o er di erent degrees of exibility. While there is no absolute metric by which to judge the degree of exibility of a system, Kiczales and Lamping [47] have identi ed a number of \qualities" that can be used to discuss the exibility of a system: incrementality refers to the degree to which the e ort necessary to specialise an implementation is proportional to the amount of change required [49]; scope control refers to the degree to which the e ect of modi cations to the implementation of a service a ect all or only some of the clients of that service { ideally such modi cations should only a ect those clients that desire it; 1 TOWARDS FLEXIBLE OPERATING SYSTEMS 4 interoperability is the degree to which applications that use non-standard mapping decisions can interact with other applications; and nally, robustness is the degree to which the implementation is graceful in the face of bugs in extensions. 1.4 Technologies for Achieving Flexibility Recent developments in operating system architecture have been dominated by the transition from so-called monolithic operating systems to those based on microkernel technology. The introduction of microkernels has been largely motivated by the promise of better support for distributed and multi-processor systems (i.e., a response to recent technological advances) as well as improved modularity and exibility albeit at the cost of poorer performance in some cases [12]. However, the use of microkernel technology is not the only possible approach to improved exibility. In fact, ve distinct, although not mutually exclusive, technologies that have been or are being employed to achieve exibility can be identi ed: microkernel technology; application-speci c operating systems;